Software defined networking distributed and dynamic mobility management

ABSTRACT

A method and apparatus are described for supporting advanced distributed and dynamic mobility management (DMM) features with multiple flows anchored at different gateways. A software defined networking (SDN) controller may support the attachment of a wireless transmit/receive unit (WTRU) to a network. The SDN controller may receive initial attachment signaling from a point of attachment (PoA) indicating that the WTRU initially attached to the network. The anchor node may be a distributed gateway (D-GW). The SDN controller may select an anchor node to serve the WTRU Internet protocol (IP) flow traffic. Initial attachment signaling, intra-anchor node handover, inter-anchor node handover, new anchor node allocation and inter-domain mobility across virtualized operators are also described.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 61/847,350 filed Jul. 17, 2013, the contents of whichare hereby incorporated by reference herein.

BACKGROUND

In contrast to current Mobile Internet protocol (IP) and Proxy Mobile IPapproaches, which rely on centralized entities for both control and dataplane operation, a distributed and dynamic mobility management (DMM)approach may utilize mobility anchors towards the edge of the network.

To enable a DMM approach, software defined networking (SDN) may be used,where the control and the data forwarding planes are separated, therebyallowing for a quicker provision and configuration of networkconnections. With SDN, network administrators may program the control ofthe traffic in a centralized way, without being required to configureindependently each of the network's hardware devices, which may alsorequire physical access to them. This approach may decouple the systemthat makes decisions about where traffic is sent, (e.g., the controlplane), from the underlying system that forwards traffic to the selecteddestination, (e.g., the data plane), potentially simplifying networkingand the deploying of new protocols and mechanisms.

OpenFlow is a standardized protocol between the control and forwardinglayers of the SDN architecture. OpenFlow may allow accessing andmodifying the forwarding plane of network devices such as switches androuters. It should be noted that OpenFlow is an example of a protocolfor the interface between control and forwarding layers.

IP mobility management may aid in providing the “always-on” andubiquitous service envisioned by future technologies. However, currentIP mobility management protocols do not necessarily meet theexpectations regarding deployment success. Accordingly, proprietarycustomized solutions are implemented instead.

SUMMARY

A method and apparatus are described for supporting advanced distributedand dynamic mobility management (DMM) features with multiple flowsanchored at different gateways. The method includes receiving an initialattachment signaling from a first point of attachment (PoA) nodeindicating that a user equipment (UE) is attached to the network. Afirst anchor node is selected to provide connectivity to the UE. Aforwarding data plan is configured to allow signaling to reach the firstanchor node, and a forwarding data plan is configured between the firstanchor node and the UE to allow data packets to be forwarded between theUE and the first anchor node.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawingswherein:

FIG. 1A shows an example communications system in which one or moredisclosed embodiments may be implemented;

FIG. 1B shows an example wireless transmit/receive unit (WTRU) that maybe used within the communications system shown in FIG. 1A;

FIG. 1C shows an example radio access network and an example corenetwork that may be used within the communications system shown in FIG.1A;

FIG. 2 shows an example of distributed and dynamic mobility management(DMM) architecture;

FIG. 3 shows an example of an SDN architecture;

FIG. 4 shows an example of an SDN-DMM architecture;

FIG. 5 shows an example of an SDN-DMM procedure for an initialattachment;

FIG. 6 shows an example of an SDN-DMM procedure for an inter-anchorhandover;

FIG. 7 shows an example of a dynamic anchoring and preconfigured IPaddressing SDN-DMM overview;

FIGS. 8A-8B show an example of an initial attachment signalingprocedure;

FIGS. 9A-9C show an example of an intra distributed gateway (D-GW)handover signaling procedure;

FIGS. 10A-10D show an example of an inter D-GW handover signalingprocedure;

FIGS. 11A-11C show an example of a new D-GW allocation signalingprocedure;

FIGS. 12A-12B show an example of internetworking of SDN and non-SDNDMM-enabled networks;

FIG. 13 shows an example of a “full-SDN” DMM network;

FIGS. 14A-14B show an example of a “full-DMM” approach for an initialattachment signaling procedure;

FIGS. 15A-15B show an example of a “full-DMM” approach for anintra-anchor handover signaling procedure;

FIGS. 16A-16C show an example of a “full-DMM” approach for aninter-anchor handover signaling procedure;

FIGS. 17A-17C show an example of a “full-DMM” approach for a new anchorallocation signaling procedure;

FIGS. 18A-18B show an example of a signaling procedure for inter-domainmobility across multiple virtualized operators;

FIG. 19 shows an example architecture of multiple SDN controllers;

FIGS. 20A-20B show an example of IP version 4 (IPv4) support for aninitial attachment signaling procedure;

FIGS. 21A-21B show an example of IPv4 support for an intra-anchorhandover signaling procedure;

FIGS. 22A-22C show an example of IPv4 support for an inter-anchorhandover signaling procedure; and

FIGS. 23A-23C show an example of IPv4 support for a new anchorallocation signaling procedure.

DETAILED DESCRIPTION

FIG. 1A shows an example communications system 100 in which one or moredisclosed embodiments may be implemented. The communications system 100may be a multiple access system that provides content, such as voice,data, video, messaging, broadcast, and the like, to multiple wirelessusers. The communications system 100 may enable multiple wireless usersto access such content through the sharing of system resources,including wireless bandwidth. For example, the communications systems100 may employ one or more channel access methods, such as code divisionmultiple access (CDMA), time division multiple access (TDMA), frequencydivision multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrierFDMA (SC-FDMA), and the like.

As shown in FIG. 1A, the communications system 100 may include WTRUs 102a, 102 b, 102 c, 102 d, a radio access network (RAN) 104, a core network106, a public switched telephone network (PSTN) 108, the Internet 110,and other networks 112, though it will be appreciated that the disclosedembodiments contemplate any number of WTRUs, base stations, networks,and/or network elements. Each of the WTRUs 102 a, 102 b, 102 c, 102 dmay be any type of device configured to operate and/or communicate in awireless environment. By way of example, the WTRUs 102 a, 102 b, 102 c,102 d may be configured to transmit and/or receive wireless signals andmay include user equipment (UE), a mobile station, a fixed or mobilesubscriber unit, a pager, a cellular telephone, a personal digitalassistant (PDA), a smartphone, a laptop, a netbook, a personal computer,a wireless sensor, consumer electronics, and the like.

The communications systems 100 may also include a base station 114 a anda base station 114 b. Each of the base stations 114 a, 114 b may be anytype of device configured to wirelessly interface with at least one ofthe WTRUs 102 a, 102 b, 102 c, 102 d to facilitate access to one or morecommunication networks, such as the core network 106, the Internet 110,and/or the other networks 112. By way of example, the base stations 114a, 114 b may be a base transceiver station (BTS), a Node-B, an evolvedNode-B (eNB), a Home Node-B (HNB), a Home eNB (HeNB), a site controller,an access point (AP), a wireless router, and the like. While the basestations 114 a, 114 b are each depicted as a single element, it will beappreciated that the base stations 114 a, 114 b may include any numberof interconnected base stations and/or network elements.

The base station 114 a may be part of the RAN 104, which may alsoinclude other base stations and/or network elements (not shown), such asa base station controller (BSC), a radio network controller (RNC), relaynodes, and the like. The base station 114 a and/or the base station 114b may be configured to transmit and/or receive wireless signals within aparticular geographic region, which may be referred to as a cell (notshown). The cell may further be divided into cell sectors. For example,the cell associated with the base station 114 a may be divided intothree sectors. Thus, in one embodiment, the base station 114 a mayinclude three transceivers, i.e., one for each sector of the cell. Inanother embodiment, the base station 114 a may employ multiple-inputmultiple-output (MIMO) technology and, therefore, may utilize multipletransceivers for each sector of the cell.

The base stations 114 a, 114 b may communicate with one or more of theWTRUs 102 a, 102 b, 102 c, 102 d over an air interface 116, which may beany suitable wireless communication link, (e.g., radio frequency (RF),microwave, infrared (IR), ultraviolet (UV), visible light, and thelike). The air interface 116 may be established using any suitable radioaccess technology (RAT).

More specifically, as noted above, the communications system 100 may bea multiple access system and may employ one or more channel accessschemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. Forexample, the base station 114 a in the RAN 104 and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as universal mobiletelecommunications system (UMTS) terrestrial radio access (UTRA), whichmay establish the air interface 116 using wideband CDMA (WCDMA). WCDMAmay include communication protocols such as high-speed packet access(HSPA) and/or evolved HSPA (HSPA+). HSPA may include high-speed downlinkpacket access (HSDPA) and/or high-speed uplink packet access (HSUPA).

In another embodiment, the base station 114 a and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as evolved UTRA (E-UTRA),which may establish the air interface 116 using long term evolution(LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station 114 a and the WTRUs 102 a, 102 b,102 c may implement radio technologies such as IEEE 802.16 (i.e.,worldwide interoperability for microwave access (WiMAX)), CDMA2000,CDMA2000 1X, CDMA2000 evolution-data optimized (EV-DO), Interim Standard2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856(IS-856), global system for mobile communications (GSM), enhanced datarates for GSM evolution (EDGE), GSM/EDGE RAN (GERAN), and the like.

The base station 114 b in FIG. 1A may be a wireless router, HNB, HeNB,or AP, for example, and may utilize any suitable RAT for facilitatingwireless connectivity in a localized area, such as a place of business,a home, a vehicle, a campus, and the like. In one embodiment, the basestation 114 b and the WTRUs 102 c, 102 d may implement a radiotechnology such as IEEE 802.11 to establish a wireless local areanetwork (WLAN). In another embodiment, the base station 114 b and theWTRUs 102 c, 102 d may implement a radio technology such as IEEE 802.15to establish a wireless personal area network (WPAN). In yet anotherembodiment, the base station 114 b and the WTRUs 102 c, 102 d mayutilize a cellular-based RAT, (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A,and the like), to establish a picocell or femtocell. As shown in FIG.1A, the base station 114 b may have a direct connection to the Internet110. Thus, the base station 114 b may not be required to access theInternet 110 via the core network 106.

The RAN 104 may be in communication with the core network 106, which maybe any type of network configured to provide voice, data, applications,and/or voice over Internet protocol (VoIP) services to one or more ofthe WTRUs 102 a, 102 b, 102 c, 102 d. For example, the core network 106may provide call control, billing services, mobile location-basedservices, pre-paid calling, Internet connectivity, video distribution,and the like, and/or perform high-level security functions, such as userauthentication. Although not shown in FIG. 1A, it will be appreciatedthat the RAN 104 and/or the core network 106 may be in direct orindirect communication with other RANs that employ the same RAT as theRAN 104 or a different RAT. For example, in addition to being connectedto the RAN 104, which may be utilizing an E-UTRA radio technology, thecore network 106 may also be in communication with another RAN (notshown) employing a GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102 a,102 b, 102 c, 102 d to access the PSTN 108, the Internet 110, and/orother networks 112. The PSTN 108 may include circuit-switched telephonenetworks that provide plain old telephone service (POTS). The Internet110 may include a global system of interconnected computer networks anddevices that use common communication protocols, such as thetransmission control protocol (TCP), user datagram protocol (UDP) andthe Internet protocol (IP) in the TCP/IP suite. The networks 112 mayinclude wired or wireless communications networks owned and/or operatedby other service providers. For example, the networks 112 may includeanother core network connected to one or more RANs, which may employ thesame RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102 a, 102 b, 102 c, 102 d in thecommunications system 100 may include multi-mode capabilities, i.e., theWTRUs 102 a, 102 b, 102 c, 102 d may include multiple transceivers forcommunicating with different wireless networks over different wirelesslinks. For example, the WTRU 102 c shown in FIG. 1A may be configured tocommunicate with the base station 114 a, which may employ acellular-based radio technology, and with the base station 114 b, whichmay employ an IEEE 802 radio technology.

FIG. 1B shows an example WTRU 102 that may be used within thecommunications system 100 shown in FIG. 1A. As shown in FIG. 1B, theWTRU 102 may include a processor 118, a transceiver 120, atransmit/receive element, (e.g., an antenna), 122, a speaker/microphone124, a keypad 126, a display/touchpad 128, a non-removable memory 130, aremovable memory 132, a power source 134, a global positioning system(GPS) chipset 136, and peripherals 138. It will be appreciated that theWTRU 102 may include any sub-combination of the foregoing elements whileremaining consistent with an embodiment.

The processor 118 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), amicroprocessor, one or more microprocessors in association with a DSPcore, a controller, a microcontroller, an application specificintegrated circuit (ASIC), a field programmable gate array (FPGA)circuit, an integrated circuit (IC), a state machine, and the like. Theprocessor 118 may perform signal coding, data processing, power control,input/output processing, and/or any other functionality that enables theWTRU 102 to operate in a wireless environment. The processor 118 may becoupled to the transceiver 120, which may be coupled to thetransmit/receive element 122. While FIG. 1B depicts the processor 118and the transceiver 120 as separate components, the processor 118 andthe transceiver 120 may be integrated together in an electronic packageor chip.

The transmit/receive element 122 may be configured to transmit signalsto, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, thetransmit/receive element 122 may be an antenna configured to transmitand/or receive RF signals. In another embodiment, the transmit/receiveelement 122 may be an emitter/detector configured to transmit and/orreceive IR, UV, or visible light signals, for example. In yet anotherembodiment, the transmit/receive element 122 may be configured totransmit and receive both RF and light signals. The transmit/receiveelement 122 may be configured to transmit and/or receive any combinationof wireless signals.

In addition, although the transmit/receive element 122 is depicted inFIG. 1B as a single element, the WTRU 102 may include any number oftransmit/receive elements 122. More specifically, the WTRU 102 mayemploy MIMO technology. Thus, in one embodiment, the WTRU 102 mayinclude two or more transmit/receive elements 122, (e.g., multipleantennas), for transmitting and receiving wireless signals over the airinterface 116.

The transceiver 120 may be configured to modulate the signals that areto be transmitted by the transmit/receive element 122 and to demodulatethe signals that are received by the transmit/receive element 122. Asnoted above, the WTRU 102 may have multi-mode capabilities. Thus, thetransceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, forexample.

The processor 118 of the WTRU 102 may be coupled to, and may receiveuser input data from, the speaker/microphone 124, the keypad 126, and/orthe display/touchpad 128 (e.g., a liquid crystal display (LCD) displayunit or organic light-emitting diode (OLED) display unit). The processor118 may also output user data to the speaker/microphone 124, the keypad126, and/or the display/touchpad 128. In addition, the processor 118 mayaccess information from, and store data in, any type of suitable memory,such as the non-removable memory 130 and/or the removable memory 132.The non-removable memory 130 may include random-access memory (RAM),read-only memory (ROM), a hard disk, or any other type of memory storagedevice. The removable memory 132 may include a subscriber identitymodule (SIM) card, a memory stick, a secure digital (SD) memory card,and the like. In other embodiments, the processor 118 may accessinformation from, and store data in, memory that is not physicallylocated on the WTRU 102, such as on a server or a home computer (notshown).

The processor 118 may receive power from the power source 134, and maybe configured to distribute and/or control the power to the othercomponents in the WTRU 102. The power source 134 may be any suitabledevice for powering the WTRU 102. For example, the power source 134 mayinclude one or more dry cell batteries (e.g., nickel-cadmium (NiCd),nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion),and the like), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to the GPS chipset 136, which maybe configured to provide location information (e.g., longitude andlatitude) regarding the current location of the WTRU 102. In additionto, or in lieu of, the information from the GPS chipset 136, the WTRU102 may receive location information over the air interface 116 from abase station, (e.g., base stations 114 a, 114 b), and/or determine itslocation based on the timing of the signals being received from two ormore nearby base stations. The WTRU 102 may acquire location informationby way of any suitable location-determination method while remainingconsistent with an embodiment.

The processor 118 may further be coupled to other peripherals 138, whichmay include one or more software and/or hardware modules that provideadditional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 138 may include anaccelerometer, an e-compass, a satellite transceiver, a digital camera(for photographs or video), a universal serial bus (USB) port, avibration device, a television transceiver, a hands free headset, aBluetooth® module, a frequency modulated (FM) radio unit, a digitalmusic player, a media player, a video game player module, an Internetbrowser, and the like.

FIG. 1C shows an example RAN 104 and an example core network 106 thatmay be used within the communications system 100 shown in FIG. 1A. Asnoted above, the RAN 104 may employ E-UTRA radio technology tocommunicate with the WTRUs 102 a, 102 b, 102 c over the air interface116.

The RAN 104 may include eNode-Bs 140 a, 140 b, 140 c, though it will beappreciated that the RAN 104 may include any number of eNode-Bs whileremaining consistent with an embodiment. The eNode-Bs 140 a, 140 b, 140c may each include one or more transceivers for communicating with theWTRUs 102 a, 102 b, 102 c over the air interface 116. In one embodiment,the eNode-Bs 140 a, 140 b, 140 c may implement MIMO technology. Thus,the eNode-B 140 a, for example, may use multiple antennas to transmitwireless signals to, and receive wireless signals from, the WTRU 102 a.

Each of the eNode-Bs 140 a, 140 b, 140 c may be associated with aparticular cell (not shown) and may be configured to handle radioresource management decisions, handover decisions, scheduling of usersin the uplink and/or downlink, and the like. As shown in FIG. 1C, theeNode-Bs 140 a, 140 b, 140 c may communicate with one another over an X2interface.

The core network 106 shown in FIG. 1C may include a mobility managementgateway (MME) 142, a serving gateway 144, and a packet data network(PDN) gateway 146. While each of the foregoing elements are depicted aspart of the core network 106, it will be appreciated that any one ofthese elements may be owned and/or operated by an entity other than thecore network operator.

The MME 142 may be connected to each of the eNode-Bs 140 a, 140 b, 140 cin the RAN 104 via an S1 interface and may serve as a control node. Forexample, the MME 142 may be responsible for authenticating users of theWTRUs 102 a, 102 b, 102 c, bearer activation/deactivation, selecting aparticular serving gateway during an initial attach of the WTRUs 102 a,102 b, 102 c, and the like. The MME 142 may also provide a control planefunction for switching between the RAN 104 and other RANs (not shown)that employ other radio technologies, such as GSM or WCDMA.

The serving gateway 144 may be connected to each of the eNode Bs 140 a,140 b, 140 c in the RAN 104 via the Si interface. The serving gateway144 may generally route and forward user data packets to/from the WTRUs102 a, 102 b, 102 c. The serving gateway 144 may also perform otherfunctions, such as anchoring user planes during inter-eNode B handovers,triggering paging when downlink data is available for the WTRUs 102 a,102 b, 102 c, managing and storing contexts of the WTRUs 102 a, 102 b,102 c, and the like.

The serving gateway 144 may also be connected to the PDN gateway 146,which may provide the WTRUs 102 a, 102 b, 102 c with access topacket-switched networks, such as the Internet 110, to facilitatecommunications between the WTRUs 102 a, 102 b, 102 c and IP-enableddevices. An access router (AR) 150 of a wireless local area network(WLAN) 155 may be in communication with the Internet 110. The AR 150 mayfacilitate communications between APs 160 a, 160 b, and 160 c. The APs160 a, 160 b, and 160 c may be in communication with STAs 170 a, 170 b,and 170 c.

The core network 106 may facilitate communications with other networks.For example, the core network 106 may provide the WTRUs 102 a, 102 b,102 c with access to circuit-switched networks, such as the PSTN 108, tofacilitate communications between the WTRUs 102 a, 102 b, 102 c andtraditional land-line communications devices. For example, the corenetwork 106 may include, or may communicate with, an IP gateway (e.g.,an IP multimedia subsystem (IMS) server) that serves as an interfacebetween the core network 106 and the PSTN 108. In addition, the corenetwork 106 may provide the WTRUs 102 a, 102 b, 102 c with access to thenetworks 112, which may include other wired or wireless networks thatare owned and/or operated by other service providers.

A packet-based network architecture definition supporting advanceddistributed and dynamic mobility management (DMM) features with multipleflows anchored at different gateways is described herein. Thisarchitecture may be enabled by using software defined networking (SDN)mechanisms, therefore providing additional flexibility to operatorsdeploying SDN-capable devices, (e.g., supporting OpenFlow) in theirnetworks.

FIG. 2 shows an example of distributed and dynamic mobility management(DMM) architecture 200. The architecture 200 may include a home publicland mobile network (HPLMN) 201 and mobile core network (MCN) 202. Inthe architecture 200, a distributed gateway (D-GW) 205 logical entitymay be placed at the edge of the network, close to a user equipment 220,(e.g., wireless transmit/receive unit (WTRU), or multiple UEs 220).Multiple D-GWs 205 may exist in a DMM domain, anchoring mobilitysessions of UEs 220 attached to the domain. In the example DMMarchitecture 200, it can be seen that various types of networks may beincluded and in communication with the HPLMN 201. For example, ThirdGeneration Partnership Project (3GPP) access cells and femto cells, andtrusted and/or untrusted non-3GPP IP access cells, any of which may haveInternet access and/or local IP network access are various types ofexample networks that may be included. In addition, the MCN 202 may beconnected to the Internet.

FIG. 3 shows an example of software defined networking (SDN)architecture 300. The SDN architecture 300 includes an application layer301, control layer 302 and an infrastructure layer 303. The applicationlayer 301 may include applications 304. The intelligence of the SDNarchitecture 300 may be centralized in a software-based SDN controller305 included in the control layer 302, which has a global view of thenetwork and is capable of controlling, in a vendor-independent way, aplurality of network devices 310, included in the infrastructure layer303. The network devices 310 may or may not be required to implement andunderstand many different network protocols standards, but may providethe needed functionality by accepting instructions from SDN controller305. A significant amount of time and resource savings may be effected,as the network behavior may be much easily controlled and modified byprogramming it in the centralized controller 305 rather than writingcomplex and long configuration files in many different devices scatteredacross the network. The applications 304 may communicate with the SDNcontroller 305 over an application programming interface (API), whilethe SDN controller 305 may communicate with the network devices 310 viaa control data plane interface, such as OpenFlow.

OpenFlow is an example of a protocol for the interface between controland forwarding layers. The apparatus and procedures described herein arenot limited to OpenFlow. Additionally, some of the mechanisms describedherein may require functionalities being currently specified inOpenFlow, (such as IPv6 support or L3 tunneling).

The mobility management schemes standardized by the Internet EngineeringTask Force (IETF) for IPv6 networks are extensions or modifications ofthe Mobile IPv6 protocol (MIPv6), such as proxy mobile IPv6 (PMIPv6),dual stack mobile IPv6 (DSMIPv6) and hierarchical mobile IPv6 (HMIPv6).However, they come at the cost of handling operations at a cardinalpoint, the mobility anchor, and burdening it with data forwarding andcontrol mechanisms for a great amount of users. This node may be faraway from the edge and deep into the core network, and although with thelatter standard it was proposed to split the management hierarchically,this may shift the problem close to the edge without really addressingthe flat IP architecture demand.

DMM may support the concept of a flatter system, in which the mobilityanchors are placed closer to the user, distributing the control and datainfrastructures among the entities located at the edge of the accessnetwork.

Centralized mobility solutions, such as mobile IPv6 or the differentmacro-level mobility management solutions of 3GPP evolved packet system(EPS), may base operations on the existence of a central entity (e.g.,home agent (HA), local mobility agent (LMA), packet data network (PDN)gateway (PGW) or gateway general packet radio service (GPRS) supportnode (GGSN)) that may anchor the IP address used by the mobile node andis in charge of coordinating the mobility management (MM). The centralentity may also be aided by a third entity such as a mobility managemententity (MME) or the home subscriber server (HSS). This central anchorpoint may be in charge of tracking the location of the UE andredirecting its traffic towards its current topological location.

While this way of addressing mobility management has been fullydeveloped by the mobile IP protocol family and its many extensions,there are also several limitations that have been identified.

For sub-optimal routing, since the (home) address used by a mobile nodemay be anchored at the home link, traffic may traverse the home agent,which may lead to paths that are, in general, longer than the direct onebetween the mobile node and its communication peer. This may beexacerbated with the current trend in which content providers push theirdata to the edge of the network, as close as possible to the users. Withcentralized mobility management approaches, user traffic may need to gofirst to the home network and then to the actual content location,adding unnecessary delay and wasting operator's resources. In adistributed mobility architecture, data paths may be shorter as theanchors are located at the very edge of the network, (i.e., close to theuser terminal).

For scalability problems, with current mobility architectures, networksmay be dimensioned to support all the traffic traversing the centralanchors. This may pose several scalability and network design problems,as the central mobility anchors may need to have enough processing androuting capabilities to be able to deal with all the mobile users'traffic simultaneously. Besides, the operator's network may need to bedimensioned to be able to cope with all the users' traffic. Adistributed approach may be inherently more scalable, as the mobilitymanagement tasks are distributed and shared among several networkentities, which therefore may not need to be as powerful as thecentralized alternative.

For reliability, centralized solutions may share the problem of beingmore prone to reliability problems, because the central entity is apotential single point of failure.

Fine granularity may be lacking on the mobility management service. Withcurrent centralized mobility management solutions, mobility support maybe offered at a user granularity. Thus, the network may determine ifmobility is provided or not to the user, but may not offer a finergranularity, for example, to allow part of the traffic of a user not tobe handled by the mobility solution. There are many scenarios in whichpart or all the traffic of a user may not need to be mobility enabled,as for example when the user is not mobile, (at least during thelifetime of the communication), or the application itself is able toeffectively deal with the change of IP address caused by the usermovement. In all these situations, it may be more efficient not toenable mobility.

Signaling overhead may be related to the previous limitation. Anymobility management solution may involve a certain amount of signalingload. By allowing mobility management to be dynamically enabled anddisabled on a per application basis, some signaling may be saved, aswell as the associated handover latency. This may depend on theparticular scenario, as the use of distributed mobility architecturesmay also lead to a higher signaling load in case of very dynamicscenarios in which all of the traffic may be mobility enabled

There are several solutions that may be capable of solving some of theaforementioned problems, such as mobile IP route optimization (RO), IPflow mobility (IFOM), 3GPP local IP access (LIPA) and selected IPtraffic offload (SIPTO) or the LIPA mobility and SIPTO at the localnetwork (LIMONET) extensions. However, the highly hierarchical andcentralized nature of existing mobile networks may make it moredifficult for the solutions to fully solve the issues of the mobilenetworks and may define extension patches that locally mitigate theidentified problems.

DMM solutions may follow the classical approach of defining and/oradapting IP mobility protocols which have a coupled control and dataplane. An SDN-based DMM solution is described herein based on thedefined evolutionary 3GPP architecture, but follows the SDN paradigm.

The SDN paradigm may be implemented in different deployments, due to theincreased flexibility it enables. While SDN has been first designed forfixed environments, the use of SDN in mobile networks is also beingconsidered. Within this scope, an SDN-enabled DMM approach provides thefollowing advantages as compared to a “classical DMM” solution. Theremay be no need of IP tunneling, thereby saving resources, there will beless signaling, there may be no need for specific protocol support inthe network, but just on the SDN controller (which has to be DMMenabled), as the rest of the network entities just need to be SDNcapable, easier and faster support for protocol updates andmodifications, and easier inter-operator support.

FIG. 4 shows an example of an SDN-DMM architecture 400, which serves asthe general framework of enabling DMM by using an SDN approach. TheSDN-DMM architecture 400 includes an HPLMN 401, MCN 402, a plurality ofD-GWs 405, and SDN controller 410, and plurality of switches 411. TheD-GWs 405 may play the role of IP anchor and may offload some trafficfrom the core network. The D-GWs 405 may be collocated with existing3GPP nodes or deployed as standalone entities. All of the 3GPP networkentities involved in the data forwarding plane, (e.g., evolved Node-Bs(eNBs), IEEE 802.11 access points (APs), femtocells, D-GWs, internalrouters and switches, PGWs/GGSNs and serving GPRS support nodes(SGSNs)/serving gateways (SGWs) may be SDN capable. The SDN controller410 may be collocated with an existing 3GPP entity (such as the HSS orthe MME).

FIG. 5 shows an example of an SDN-DMM procedure for an initialattachment. FIG. 6 shows an example of an SDN-DMM procedure for aninter-anchor handover. Both FIGS. 5 and 6 are substantially similar tothe example architecture 400 as shown in FIG. 4.

When a UE 420 attaches to the network and requests a PDN connection,this signaling may be captured by the layer 2 (L2) SDN attachment point,(e.g., the first SDN-enabled data forwarding entity, which may beprogrammed centrally by the SDN controller 410), and is forwarded to theSDN controller 410. The SDN controller 410 may have a securecommunication channel with every SDN-capable device in the network,allowing the monitoring and configuration of the different devices. Forpurposes of example, the first SDN-enabled data forwarding entity asshown in FIG. 5 is the base station switch in the 3GPP femtocell,however any SDN-enabled data forwarding entity could be the firstSDN-enabled data forwarding entity. In addition, the UE 420 could attachfirst to a non SDN-enabled device.

The SDN controller 410, which may have the global view of the network,may determine which is the best suitable anchor for the requested PDNconnection and UE 420. This determination may take into considerationmany different aspects, such as the position of the UE 420, its expectedmobility pattern, the characteristics of the requested PDN connection,and the application requesting it, (mobility requirements, expectedlifetime, and the like), among other aspects. The selected anchor may bea D-GW 405 or a centralized P-GW. The determination may be undertaken bythe SDN controller 410 itself, (i.e., network-based), by anothercentralized entity in the network (also network-based), or even by theterminal (client-based).

The SDN controller 410, based on the selected anchor, may configure thedata forwarding in all required network entities, (shown by the lightdashed lines between the SDN controller 410 and the example entities inFIG. 5), so that there is a data path between the UE 420 and the anchor,and between the anchor and the operator's network devices providingconnectivity to the services requested by the UE 420 (e.g., to theInternet, or to a local IP network). The data path between the UE 420and the anchor may not be symmetric. In the example shown in FIG. 5, thedata path is shown by the dark dashed line, which proceeds from the UE420 to the D-GW 405 shown through the switch 411 shown in FIG. 5.

The UE 420 may finalize the L3 connection/association, and may configurean IP address anchored at the selected anchor. The selected anchor maybe a D-GW 405 closer to the UE 420, and the configured IP address may belocally anchored at the D-GW. In this way, traffic may not traverse theoperator's core.

If the UE 420 performs a handover as depicted in FIG. 6, the handoversignaling may again be forwarded to the SDN controller 410, which maydecide if a new anchor has to be selected. If no new anchor is selected,the SDN controller 410 may configure the data forwarding plane in thenetwork, (e.g., using OpenFlow), so that traffic may be exchangedbetween the anchor and the UE.

If a new anchor is selected, the SDN controller may configure thenetwork (using OpenFlow) so that both the traffic using the IP addressanchored at the former anchor may reach the UE 420 at its new location,as well as a new path may be established between the UE 420 and the newanchor. This new path, again depicted by a second dark dashed line inFIG. 6, may be used by the new anchor to provide a new IP address to theUE, which may use it for new communications. Again, this path may beasymmetric.

The SDN controller is in charge of configuring the data forwarding path,(depicted by the light dashed lines in FIG. 6), to ensure that the UE420 may also use the new IP address. No tunnels are required between theanchor and the current point of attachment, nor between anchors, as thedata forwarding may be dynamically updated using SDN, (e.g., OpenFlowprotocol between the controller and the network programmableswitches/routers).

If more handovers are performed, the same procedure may be repeated,selecting, if needed, a new anchor, and configuring the network so thereis an L3 link between the UE 420 and each of the active anchors. Fromthe point of view of the UE 420, each handover that involves a newanchor selection may be treated as if a new router was turned on in thenetwork and a new IPv6 address is configured.

Different procedures are described following the paradigm of an SDN-DMMsolution. Different approaches may be adopted depending on thedeployment model that is used and the specific support available on thenetwork nodes.

FIG. 7 shows an example of a dynamic anchoring and preconfigured IPaddressing SDN-DMM overview 700. As shown in FIG. 7, an MCN 702, aplurality of Points of Access (PoA01, PoA02, and PoA03) 703, D-GWs(D-GW1 and D-GW2) 705, a SDN controller 710, switches 711 (SW01-SW17),and a UE 720 are included. The MCN 702 is connected to several switches,(e.g., SW13-16), and the UE 720 is shown in communication with PoA01.Dynamic anchoring using regular IP routers as anchors may provide aprocedure that minimizes extra required support in addition toSDN-capable L2/L3 switches and regular IP routers (used as anchors).Several D-GWs may be deployed in the access network, composed of networkswitches (SWs) which may be SDN-capable. The D-GWs may have directconnectivity to the Internet and/or to local IP services, allowing localbreakout to be provided to the UEs. Each D-GW may manage at least onelocally anchored IPv6 prefix, which may be preconfigured in advance, andmay be available for UEs to auto-configure IP addresses from, (eitherusing stateless or stateful IP address auto-configuration mechanisms).The D-GW may not perform any specialized function, and may basicallyacts as a L3 router. By using SDN, the network may provide seamless IPmobility to attaching UEs. Each D-GW 705 may advertise a prefix that isused by the UE 720 to auto configure an IP address. For example, whenthe UE 720 connects to D-GW1, it may use an IP address from PrefA::/64,and when connecting to D-GW2, Pref B::/64 may be advertised and used bythe UE 720. Additionally, if more than one UE is connected to the sameD-GW, each UE may be provided a different prefix for use.

FIGS. 8A-8B shows an example of initial attachment signaling procedure800 used when a UE initially attaches to the network. As shown in FIGS.8A-8B, UE1, (which may include any UE or WTRU described above), mayattach to the network. Irrespective of the technology utilized toattach, the point of attachment is SDN enabled. This L2 point ofattachment (PoA) may be configured, either by default or by a SDNcontroller upon network bootstrapping, to forward initial attachmentsignaling (including PDN connection requests) to the SDN controllerusing a secure SDN channel (e.g., using OpenFlow).

The SDN controller may check if UE1 is already attached to the network.This may be done by consulting an external mobility database (e.g., theHSS) or internal database. The first model may facilitate deploymentmodels in which either not all the network is SDN capable, or thesupport of hierarchical controllers for large domains. If the UE1 hasjust attached to the network (there is no previous activecommunications), the SDN controller may decide the best D-GW, (or justan anchor, in a more general case), to serve UE1, based on its knowledgeof the network status, network capabilities, and the like. In this case,D-GW1 may be selected, and the SDN controller may update theinternal/external mobility database with the selected D-GW, and also mayinclude information about the data plane to be configured in the network(so it may be later updated/removed). In this example, the controllermay update the HSS, thereby serving the purpose of allowingcompatibility with non-SDN parts of the network. The use of the HSS isan example entity, utilizing the 3GPP architecture as a referencetechnology, but it may be a different node, where a logical mobilitydatabase of the information about attached UEs, associated IP prefixesand responsible D-GWs may be stored.

Then, the SDN controller may configure the forwarding plane to allow theL3 signaling (e.g., router solicitation) to reach D-GW1. D-GW1 may bepreconfigured to allocate PrefA::/64 for IP address autoconfiguration.Stateless address autoconfiguration may be used in this example, butstateful mechanisms such as DHCPv6 may also be used.

UE1 may configure an IP address (PrefA::UE1/64) out of the prefixadvertised by D-GW1, and configure D-GW1 as its default router. The SDNcontroller may configure the forwarding plane to allow the IPv6 datapackets to be forwarded between UE1 and D-GW1, following the pathUE1<->PoA 01<->SW01<->SW05<->D-GW1. While in this example symmetricpaths are used, the controller may have selected different paths fromUE1 to D-GW1, and from the D-GW1 to UE1, depending for example on thenetwork conditions. From this point, traffic from the UE1 may beforwarded from the L2 PoA towards D-GW1, and from there to the next hopstowards the final destination.

The selected D-GW may not be collocated with the L2 PoA, but thatdeployment configuration is also possible. The SDN controller may be alogical entity that may also be collocated with different networkentities, such as the HSS.

FIGS. 8A-8B show detailed examples of control data plane interfacesignaling messages (using OpenFlow as an example). These messages mayshow the most relevant parameters, but there may be other fields, suchas the lifetime of the flow entries that omitted, as they may beselected based on the particular network deployment. Similarly, the flowconfigurations shown may be based on L2 and L3 source and destinationaddresses. A different set of flow match fields may be used, such as theswitch ingress port, or may be based upon L2 and/or L3 addresses, forexample.

The OpenFlow message names are not shown in FIGS. 8A-8B. However, moregeneric names may be applied to other control protocols. For example,when “Add flow” is used, the OpenFlow message may be acontroller-to-switch modify-state message with an OFPFC₁₃ MODIFYcommand. It should again be noted that the signaling shown in FIGS.8A-8B is exemplary, and that alternative signaling may be utilized.

FIGS. 9A-9C show an example of an intra D-GW handover signalingprocedure 900, where the UE may change its L2 point of attachment, butmay still be managed by the same D-GW. The procedure is similar to theinitial attachment procedure 800. When UE1 attaches to the new PoA(PoA02), the latter may be configured to forward this initial attachmentsignaling to the SDN controller. The SDN controller may check if UE1 wasinitially attached to the network (this may involve communication withan external mobility database, such as the HSS). In this example, UE1was previously attached to the network (i.e., it is a handover case, notan initial attachment to the network) and it may have one active prefix,managed by D-GW1. The SDN controller may determine that the anchorremains to be D-GW1 based on different kinds of information that mayinclude, but are not restricted to, network status, load, known mobilitypatterns of UE1, and the like.

Since the topological location of the UE1 has changed and the assignedserving D-GW remains the same, the SDN controller may update theforwarding data plane to allow L3 signaling to be delivered betweenD-GW1 and UE1, in this case following a different path:UE1<->PoA02<->SW03<->SW02<->SW05<->D-GW1, in accordance with thesignaling depicted in FIGS. 9A-9C. The same prefix (PrefA::/64) maycontinually be advertised to UE1, which enables UE1 to maintain the sameIP address (PrefA::UE1) and default gateway.

The SDN controller may also update the forwarding plane to allow theIPv6 data packets to be forwarded between UE1 and D-GW1, following thenew path UE1<->PoA02<->SW03<->SW02<->SW05<->D-GW1. In both cases, theupdate may involve removing the flow entries that were added during theattachment to PoA01 and adding the new ones. From this point, trafficfrom UE1 may be forwarded from the PoA02 towards D-GW1, and from thereto the next hops towards the final destination. UE1 may not be aware ofany L3 mobility as it may be provided with network-based mobilitysupport in a transparent way. It should again be noted that thesignaling shown in FIGS. 9A-9C is exemplary, and that alternativesignaling could be utilized.

FIGS. 10A-10D show an example of an inter D-GW handover signalingprocedure 1000 for the case of a UE handover which involves theselection of a new D-GW. As in the previous cases, when UE1 attaches toa new PoA, the attachment signaling may be forwarded to the SDNcontroller, which may check if UE1 has any active prefix and performsD-GW selection. In this case, a new D-GW may be selected (D-GW2). Sincethe anchor has changed, a new IP prefix may be assigned to UE1, and theold one may be deprecated (one or more prefixes may be anchored). Inorder to deprecate the old IP address (PrefA::UE1), the SDN controllermay generate a set of router advertisement (RA) messages with zerolifetime. If OpenFlow is the protocol used by the SDN controller, thismay be performed with a packet-out controller-to-switch message. Inorder to enhance the likelihood that UE1 receives the message, more thanone RA may be sent, such as 3 in the example depicted in FIGS. 10A-10D.From this point, UE1 may not use the old IP address for newcommunications, but continue using them for ongoing communications.

The SDN controller may update the forwarding data plane to allow L3signaling to be delivered between D-GW2 and UE1, in this case using thefollowing path: UE1<->PoA03<->SW04<->SW07 <->D-GW2. Since the anchor mayhave changed, a new prefix (locally anchored at D-GW2) may be advertisedto UE1 (PrefB::/64), which may configure a new IP address (PrefB::UE1)and default gateway (D-GW2).

The SDN controller may also update the forwarding plane to allow theIPv6 data packets to be forwarded between UE1 and D-GW1, ensuring thatongoing sessions using the IP address PrefA::UE1 follows the new pathUE1<->PoA03<->SW04<->SW03<->SW02<->SW05<->D-GW1. Traffic usingPrefA::UE1 may be forwarded from PoA03 towards D-GW1, and from there tothe next hops towards the final destination. In this way, UE1 may keepusing the old address for ongoing communications, while using the new IPaddress (PrefB::UE1) for new communications.

No additional support is required on the UE. The selection of a new D-GWfor new communications and the interruption of using the old D-Gw(s),once active communications using prefixes anchored by other D-GW(s) arefinished, may be achieved using standardized IPv6 mechanisms. From thepoint of view of the UE, it may be equivalent to having new IP routersappearing and disappearing from the link (and deprecating theiraddresses as in a renumbering process). Although the network may need toimplement new functionality, and the SDN controller may need to havethis intelligence, the rest of the network may just need to beSDN-capable, (no DMM specific functionality is required).

In all of the aforementioned procedures, tunneling may not be requiredbetween D-GWs to ensure address reachability due to the use of dynamicL2 forwarding reconfiguration, which may allow SDN-capable networkentities to be easily and quickly updated to perform forwarding on a perflow level.

FIGS. 11A-11C show an example of a new D-GW allocation signalingprocedure 1100 for situations in which the network may determine that itis better to allocate a new D-GW to a UE, even if the UE has not moved,(e.g., because of planned maintenance or network load).

As shown in FIGS. 11A-11C, UE1 may currently be using only IP addressesanchored by D-GW1 when the network (the SDN controller) decides toallocate a new anchor to UE1 (D-GW2), and a new locally anchored IPprefix (PrefB::/64). The SDN controller may update the database withthis information and proceed to deprecate the IP address allocated bythe previously assigned anchor (PrefA::UE1), in this case by sendingseveral RAs including a prefix information option (PIO) with PrefA::/64and zero lifetime. This is an example for the case of stateless IPv6address configuration. Then, the SDN controller may update the data pathforwarding in the network, removing the status required for the L3signaling to be delivered between D-GW1 and UE1, and installing the onerequired for that L3 signaling to flow between D-GW2 and the UE1. Inthis example, the following path may be selected:UE1<->PoA02<->SW03<->SW07 <->D-GW2 (an asymmetric path may also beused). Since the anchor has changed, a new prefix (locally anchored atD-GW2) may be advertised to UE1 (PrefB::/64), which may configure a newIP address (PrefB::UE1) and default gateway (D-GW2).

The SDN controller may install the required state on the network nodesto allow the IPv6 data packets to be forwarded between UE1 and D-GW2,ensuring that ongoing sessions using the IP address PrefB::UE1 mayfollow the computed path UE1<->PoA02<->SW03<->SW07 <->D-GW2. Trafficusing PrefA::UE1 may still be forwarded towards D-GW1, and from there tothe next hops towards the final destination. In this way, UE1 may keepusing the old address for ongoing communications, while using the new IPaddress (PrefB::UE1) for new communications.

The architectures described and depicted above describe homogeneousnetworks, in which all of the switches are SDN-capable. However, theremay be deployments in which SDN-enabled portions of a network may beinterconnected with non-SDN portions. FIGS. 12A-12B show an example ofinternetworking of SDN and non-SDN DMM-enabled networks 1200. Thisscenario may be supported by enabling full DMM support on the anchorsdeployed on the SDN-capable part of the network and using the HSS as aglobal mobility database. The architecture depicted in FIGS. 12A-12Bincludes a non-SDN network 1201, an MCN 1202, and an SDN-capable network1203. A plurality of D-GWs 1205, (e.g., D-GW1 . . . D-GW5), are includedand depicted in both the non-SDN network 1201, (e.g., D-GW3 . . .D-GW5), and SDN-capable network 1203, (e.g., D-GW1 and D-GW2). Thearchitecture also includes PoAs01, 02, and 03, switches 1211, and UEs1220, as shown.

Since the HSS keeps the registry of where each UE 1220 is anchored(D-GW) and the prefix used by the UE 1220, when a UE 1220 roams to anon-SDN part of the network 1201, the serving D-GW1 may send thesignaling required to establish a tunnel between the serving D-GW andthe active anchoring D-GWs. As long as the SDN-capable and the non-SDNparts of the network are connected, and the HSS contains the mobilitydatabase, D-GWs may set-up the required tunnels to support mobility.

In the embodiments described above, in addition to a DMM capablenetwork, the deployment of D-GWs as potential anchors for UE traffic maybe utilized. These D-GWs may be pre-allocated with some IPv6 prefixesand configured to act as IPv6 routers.

FIG. 13 shows an example of a “full-SDN” DMM network 1300 in which allof the SDN functionality may be implemented via the programming of theSDN network switches from the SDN controller. Thus, only SDN-capableL2/L3 switches may be required. The network 1300 includes an MCN 1302,PoAs 1303, an SDN controller 1310, Switches 1311, and a UE 1320.

As shown in FIG. 13, the network 1300 may be composed of severalSDN-capable switches (SWs01-17). Some of the SDN-capable switches may beconnected to wireless points of attachment, and some others may havelocal Internet connectivity, meaning that they may serve as localbreak-out points. R01 and R02 may be routers providing networkconnectivity and/or access to local network/services. For purposes ofexample, the example signaling procedures depicted in FIGS. 14-18 belowrefer to the network structure depicted in FIG. 13 as a referencenetwork structure.

FIGS. 14A-14B show an example of a “full-DMM” approach for an initialattachment signaling procedure 1400 when a UE initially attaches to thenetwork. In FIGS. 14A-14B, UE1 performs a L2 attachment to PoA01. Theinitial L3 attachment signaling of the UE may serve as a trigger for thesignaling, as PoA01 has no rule for that kind of traffic. OpenFlow maybe used as a southbound configuration protocol for the SDN network, butother protocols may also be used.

Alternatively, the L2 attachment signaling may also be used as theinitial trigger. Since PoA01 has no forwarding rule for this initialattachment signaling packet, PoA01 may forward it to the SDN controller,which then may check in a database, (that may be centralized, forexample in the HSS), if UE1 was previously attached to the network. Inthis case (initial attachment), no information about UE1 may be found onthe database, so the SDN controller may select which node of the networkmay be anchoring the traffic of the UE1, (or the particular flow thatthe L3 signaling is trying to set-up, if that information is availableat this stage, e.g., for the case of a PDN connectivity request).

This determination may take into account different aspects, such as theexpected mobility pattern of the UE, previous known patterns, its speed(if known), the status of the network, and the like. The SDN controllermay not only select an anchoring node, i.e., which node may be used tolocally break-out the traffic (SW05 in this example, which has local IPconnectivity via R01), but also a locally anchored IPv6 address/prefixto be delegated to UE1 (PrefA::/64) in this example. Once the anchor andIP address/prefix are selected, the SDN controller may calculate thepath that UE1 traffic (or specific UE1 flow) may follow(PoA01<->SW01<->SW05<->R01 in this case), and may update the databasewith all of this information. Then, the SDN controller may generate thesignaling in response to the L3 attachment message sent by the UE, so itmay configure the right IP address and additional IP parameters (e.g.,default router). In the example shown in FIGS. 14A-14B, stateless IPv6address autoconfiguration may be implemented, so that the SDN controllermay generates an RA containing the prefix allocated to UE1 (PrefA::/64).In order to avoid a potential loss of the message on the wirelesschannel, the message may be sent several times. This message is sent 3times in the example shown in FIGS. 14A-14B. Out of this prefix, UE1 mayconfigure an IPv6 address (PrefA::UE1/64) and set up a default route viathe selected anchor (SW05). In order to make the mobility transparent tothe UE, the L2 and L3 addresses of the default router used by UE1 may bekept the same, regardless of its point of attachment to the network,(for each anchor the UE is using). Depending on the configuration of thenetwork, these addresses may be selected by the anchor (SW05 in thisexample) or by the SDN controller. In this case, that information mayalso be maintained in the database, to avoid address collisions.

The SDN controller may configure the forwarding plane of the involvedentities in the network, so IPv6 packets from/to UE1 can flow via theselected anchor, and using the best path within the network. This pathmay not necessarily be the shortest path, as other considerations (suchas network status and load) may be taken into consideration by the SDNcontroller when computing it.

FIGS. 14A-14B also show detailed examples of control data planeinterface signaling messages (using OpenFlow just as an example). Thesemessages show relevant parameters, but there may be other fields, suchas the lifetime of the flow entries that are omitted, as they may beselected based on the particular network deployment. Similarly, the flowconfigurations shown may be based on L3 source and destinationaddresses. However, a different set of flow match fields may be used,such as the switch ingress port, or include both L2 and L3 addresses,for example. Although message names related to OpenFlow message namesmay or may not be used in FIGS. 14A-14B, other message names may beapplied to other control protocols. For example, when “Add flow” isused, the OpenFlow message may be a controller-to-switch modify-statemessage with a OFPFC_MODIFY command.

FIGS. 15A-15B show an example of a “full-DMM” approach for anintra-anchor handover signaling procedure 1500 when a UE performs ahandover that does not involve a change of anchor. UE1 may perform an L2handover to PoA02. When PoA02 receives the attachment signaling sent byUE1, it may find that it does not have any matching forwarding rule forthe received packet, and therefore it may forward the packet to the SDNcontroller. The SDN controller may look for UE1 in the database, (in theexample this database is hosted at the HSS), and may find out that UE1was already attached to the network and may obtain the active prefixesin use by the UE, as well as the set-up forwarding data paths. Takingthat information as input, together with other parameters, (such as, butnot limited to, network status, UE speed, UE known past mobilityrecords, application mobility requirements, and the like), the SDNcontroller may determine if a change of anchor is necessary or not. Inthis case, the anchor may not need to be changed (i.e, intra anchorhandover). Therefore, the SDN controller may compute the best path fromand to the anchoring entity (SW05) and the current attachment point ofUE2 (PoA02), which in this example may bePoA02<->SW03<->SW02<->SW05<->R01. The selected path may also beasymmetric (i.e., different downlink and uplink paths). The SDNcontroller may update the database with the new information about theselected forwarding path and current attachment of UE2.

The SDN controller may generate the signaling in response to the L3attachment message sent by the UE, so it may keep using the same IPaddress (and default router), so UE1 effectively may not notice anymobility at the IP layer. In the example shown in the FIGS. 15A-15B,stateless IPv6 address autoconfiguration may be implemented, so the SDNcontroller may generate an RA containing the prefix allocated to UE1(PrefA::/64). In order to avoid a potential loss of the message on thewireless channel, the message may be sent several times (3 in theexample shown in FIGS. 15A-15B). Since this is the same prefix that UE1was using, and it is advertised by the same router (meaning, same L2 andL3 addresses), UE1 may not detect any mobility and may keep using thesame IPv6 address (PrefA::UE1/64).

The SDN controller may then update the data forwarding configuration inthe network, by sending configuration signaling to all involved networkentities, so that the new computed data paths between the anchor (SW05)and the UE (attached to PoA02) may be used.

FIGS. 16A-16C show an example of a “full-DMM” approach for aninter-anchor handover signaling procedure 1600 when a UE performs ahandover that involves a change of anchor. UE1 may perform an L2handover to PoA03. When PoA03 receives the attachment signaling sent byUE1, it may find that it does not have any matching forwarding rule forthe received packet, and therefore it may forward the packet to the SDNcontroller. The SDN controller may look for UE1 in the database (in theexample this database is hosted at the HSS) and may find out that UE1was already attached to the network and may obtain the active prefixesin use by the UE, as well as the set-up forwarding data paths. Takingthat information as input, together with other parameters (such as, butnot limited to, network status, UE speed, UE known past mobilityrecords, application mobility requirements, and the like), the SDNcontroller may decide if a change of anchor is necessary or not. In thiscase, a new anchor may be selected (inter anchor handover), togetherwith a new locally anchored IP prefix (PrefB::/64). The SDN controllermay compute the best path from and to the new anchoring entity (SW07which is connected to a network with local IP connectivity via R02) andthe current attachment point of UE2 (PoA03), which in this example maybe PoA03<->SW04<->SW07<->R02. The SDN controller may also compute thebest path from the current attachment point and the anchoring point ofother active prefixes (PrefA::/64 in this case). As before, selectedpaths may be asymmetric (i.e., different downlink and uplink paths). TheSDN controller may update the database with the new information aboutthe selected forwarding paths, active anchors, prefixes and currentattachment of UE2.

Then, the SDN controller may generate the signaling in reply of the L3attachment message sent by the UE. On the one hand, the SDN controllermay deprecate the IP address(es) used by the UE anchored at differentnodes than the current selected anchor. In the example shown in FIGS.16A-16C, this may be performed by the SDN controller generating andsending an RA message with zero lifetime for each IPv6 prefix to bedeprecated (PrefA::/64 in this example). Several of these messages maybe sent to improve the reliability. The reception of these messages maymake UE1 deprecate the address it has configured out of the deprecatedprefix, which means that this address (PrefA::UE1 in the example) mayonly be used for ongoing sessions that were established before the UEmoved. On the other hand, the SDN controller may also generate thesignaling required to allow UE2 configure an IP address out of the newlocally anchored prefix (PrefB::/64). In this example, this may beperformed by sending a new RA message containing the new prefix (thismessage is also sent several times). The new configured address(PrefB::UE2) may be used for new sessions of UE1.

The SDN controller may then update the data forwarding configuration inthe network, by sending configuration signaling to all involved networkentities, so that the data paths may support the communication betweenthe current attachment point (PoA03) and the different anchoringentities. This may ensure that traffic follows the right path (bothuplink and downlink, which may be asymmetric) for both applicationsusing PrefA::UE1 and applications using PrefB::UE1.

FIGS. 17A-17C show an example of a “full-DMM” approach for a new anchorallocation signaling procedure 1700 when the network decides to allocatea new anchor to a UE, even if the UE1 has not moved. UE1 is currentlyusing only IP addresses anchored by SW05 and the network (the SDNcontroller) may decide to allocate a new anchor to UE1 (SW07, which hasconnectivity with R02), and a new locally anchored IP prefix(PrefB::/64). The SDN controller may update the database with thisinformation and may proceed to deprecate the IP address allocated by thepreviously assigned anchor (PrefA::UE1), in this case by sending severalRAs including a PIO option with PrefA::/64 and zero lifetime. This is anexample for the case of stateless IPv6 address configuration. The SDNcontroller may also generate the signaling required to allow UE2configure an IP address out of the new locally anchored prefix(PrefB::/64). In this example, this may be performed by sending a newRouting Advertisement message containing the new prefix (this message isalso sent several times). The new configured address (PrefB::UE2) may beused for new sessions of UE1. Then, the SDN controller may compute thebest path from and to the new anchoring entity (SW07) and PoA02, whichin this example may be PoA02<->SW04<->SW07<->R02 (note that asymmetricpaths may also be computed).

FIGS. 18A-18B show an example of a signaling procedure 1800 forinter-domain mobility across multiple virtualized operators. Havingmultiple virtual operators sharing part or all of a physical network maybe a deployment scenario, as using SDN tools allow to do so quiteeasily. In this scenario, a UE handover may belong to one of thefollowing categories.

In one category, the UE may move between L2 PoAs that may be controlledby its operator, (i.e., its operator is part of the operators' setsharing both the old and the new L2 physical PoA), the selected D-GW mayalso be controllable by the same operator, and the network elementsbetween the L2 PoAs, and the involved D-GWs (if a new one is selected asa result of the handover) may also be controllable by the same operator.In this case, the handover may actually be an intra-domain one, so nonew considerations may be needed.

In another category, the UE may move from one L2 PoA that may becontrolled by its operator to another that cannot (i.e., the operator isnot part of the operators' set that can control the physical new L2PoA), and/or the involved D-GWs may not be all controllable by theoperator and/or the network entities between the L2 PoAs and D-GW(s) maynot be controllable by the operator. The involved operators may haveroaming agreements in place that allow their respective SDN controllersto cooperate in order to achieve inter-domain mobility.

In yet another category, the UE may move from one L2 PoA that may becontrolled by its operator to another that may not (i.e., the operatoris not part of the operators' set that can control the physical new L2PoA), and/or the involved D-GWs may not be all controllable by theoperator and/or the network entities between the L2 PoAs and D-GW(s) maynot be controllable by the operator. The involved operators may not haveroaming agreements in place that allow their respective SDN controllersto cooperate to achieve inter-domain mobility. In this case, the onlymobility support that may be provided is via a centralized anchor thatmay be supported.

As shown in FIGS. 18A-18B, UE1 may move from an L2 PoA from Operator Xto an L2 PoA managed by a different Operator Y, and also the newselected D-GW (D-GW2) may belong to Operator Y. When UE1 moves to thenew L2 PoA, managed by Operator Y, this PoA may forward the handoversignaling to its SDN controller (SDN controller Y), which may check withits mobility database (HSS Y in this example) if UE1 has an activeprevious prefix (either managed by Operator Y or another operator). Inthe handover signaling, UE1 may convey information about the operator towhich it was previously attached. The HSS Y may make contact with themobility database of the operator previously visited by UE1 (HSS X), andobtain the information about the active prefixes, the associated anchorsand SDN controllers, as well as an authorization key that may be laterused by the SDN controller Y to request SDN controller X to perform someforwarding configuration. All this information may be provided to SDNcontroller Y, which may select the best anchor for UE1. In this case,D-GW2 may be selected, which may be controlled by Operator Y. The SDNcontroller Y may send all of the configuration commands to the networksentities that may be controlled by it, as well as may request SDNcontroller X to do the same with those entities that may only be managedby Operator X. SDN controller Y may use the authorization key to signthis request. Alternative mechanisms may be used to authorize an SDNcontroller from one operator request forwarding configuration operationsto an SDN controller managed by a different operator. This signaling mayalso include the request to deprecate all active prefixes (PrefA::/64),but the one just assigned by D-GW2 (PrefB::/64).

As in the previous cases, UE1 may still use PrefA::UE1 for ongoingcommunications and use PrefB::UE1 for new ones, being the mobilitysupport provided in a transparent way. No tunneling may be needed, asthe network may be dynamically reconfigured to setup the different datapaths required to ensure the reach ability of the different activeprefixes, even if different operators are involved.

FIG. 19 shows an example architecture 1900 of multiple SDN controllers.The architecture 1900 includes an MCN 1902, a plurality of PoAs(PoA01-03), SDN controllers 1910 (01 and 02), switches 1911 (SW01-SW17),and a UE 1920. In some deployments, it may be necessary to deploymultiple SDN controllers 1910, for example to alleviate the load on theSDN controller. This may be enabled by ensuring that every deployed andactive SDN controller 1910 has access to a common database. An examplemay be co-locating that database with the HSS, but other approaches mayalso be utilized, such as using a distributed database, or replicatedcopies of the database on the SDN controllers 1910 and then using areplication protocol to ensure the information is kept consistent andup-to-date.

There may be different potential models of deployment of multiplecontrollers. For example, each SDN-capable network switch 1911 may beconfigured with a default SDN controller 1910, which may be the onereceiving packets for which the network switch 1911 cannot find anactive mapping/flow entry. This default SDN controller 1910 may beresponsible for configuring the network switches 1911 under itsinfluence area, but the may be other devices that can do it. Forexample, a UE 1920 may perform a handover from a PoA 1903 handled by adifferent controller than the one handling the target PoA, or thecomputed path for a given UE flow may involve traversing switches 1911that are primarily handled by a different controller. With protocols,such as OpenFlow, each network switch 1911 may be configured by multiplecontrollers. In order to support a consistent operation, everycontroller may have access to up-to-date information about UE status,(e.g., active anchors, IP addressing information, configured data paths,and the like). All SDN-capable network switches 1911 may be accessibleby all deployed controllers, so that they may receive configurationcommands.

In addition to the procedures described above, there are two examplescenarios that may be considered to support IPv4. In a first scenario,each potential anchor may be able to provide a unique public IPv4address to each UE. In a second scenario, each potential anchor may haveone or a limited pool of public IPv4 addresses, and may allocate privateIP addresses to UEs and performs network address translation (NAT). Thefirst scenario is similar to the IPv6 one except that additional supportmay be required on the UE, (e.g., on the connection manager), side tohandle different IPv4 addresses simultaneously, but the solution on thenetwork side may be similar to IPv6. On the other hand, the secondscenario may require additional functionality and is described furtherbelow.

The SDN-based solution for DMM with IPv4 support may be implemented asfollows. Referring back to FIG. 13, in a network similar to network1300, each SDN-capable switch attached to a local IP network may have alimited pool of public IPv4 addresses, and the SDN controller 1310 maycentrally implement the NAT control functionality, programmingaccordingly some network switches to perform the NAT data-planeforwarding operations, (i.e., address and port translation, plusapplication layer gateway functions). Alternatively, a real NAT box maybe deployed close/co-located with each network switch playing an anchorrole, but a dedicated interface between this NAT and the SDN controllermay be utilized in this case. The SDN controller 1310 may determinewhich network switch 1311 is operating in the anchor role, and mayselect a private IP address to be allocated to the UE 1320 on initialattachment to the network. Then, forwarding state is populated on thenetwork based on the private IPv4 address allocated to the UE 1320, thedestination address and the used ports. If the UE 1320 changes anchor,meaning that a new public IPv4 address (anchored at the new anchor) maybe used for new communications, the same private IPv4 address may beallocated to the UE 1320. The network may distinguish the right anchorfor each data packet based on the addresses and ports used, so trafficmay be forwarded to the right anchor, which performs the required NATtransformations.

FIGS. 20A-20B show an example of IP version 4 (IPv4) support for aninitial attachment signaling procedure 2000 when a UE initially attachesto the network. When UE1 attaches to the network (PoA01), the initialattachment signaling may be received by PoA01, which may not have amatching rule for this traffic, and therefore may forward it to the SDNcontroller. The controller may check the database to determine if thereis status information about UE1, which may not be the case as it is theinitial attachment of the UE1. Then, the SDN controller may select anunused private IPv4 address to allocate to the UE (10.0.1.1/24), anaddress for the default router (10.0.1.2), and select where the trafficmay be anchored in the network, (in this case, SW05 may be selected asthe break-out point, which may be attached to a local IP network withInternet access via R01) and an associated public IPv4 address(192.0.2.1). The SDN controller may generate the reply signalingmessages, which may convey the allocated private IPv4 address andadditional IP configuration parameters. For example, this signaling maybe dynamic host configuration protocol (DHCP) or point-to- pointprotocol (PPP). The controller may also update the database with thisnew information.

When UE1 sends its first IPv4 data packets, these packets may bereceived by PoA01 and there may not be any matching rules. Therefore,these packets may also be forwarded to the SDN controller, which maycompute the NAT required translation and set up the forwarding dataplane in the network (in this case, following the pathUE1<->PoA01<->SW01<->SW05<->R01, which may be symmetric just for thesake of simplifying the example). The controller may configure thedifferent involved network entities, including not only the data planeforwarding entries, but also the packet level transformations that maybe performed at the anchoring point which is also playing the role ofNAT device (SW05 in this example). In FIGS. 20A-20B, only one IP dataflow may be considered, showing the NAT operations and the flow pathforwarding setup in the network. For each new flow of the UE, analogousoperations may take place.

FIGS. 21A-21B show an example of IPv4 support for an intra-anchorhandover signaling procedure 2100. If UE1 changes its point ofattachment and connects to PoA02, the initial attachment signaling maybe received by PoA02, which may forward this signaling to the SDNcontroller, as PoA02 does not have a mapping for that traffic. The SDNcontroller may look into the database for UE1 and find out that it wasalready attached to the network, and obtain the information aboutcurrent anchors, allocated addresses and NAT state. Taking thisinformation into consideration, together with additional one, such as,but not limited to, network status, UE known mobility pattern, and thelike, the SDN controller may decide to keep current anchor point forUE1's traffic. Therefore, the controller may compute the new best pathfor UE1's traffic (UE1<->PoA02<->SW03<->SW02<->SW05<->R01 in thisexample) and update involved network entities.

FIGS. 22A-22C show an example of IPv4 support for an inter-anchorhandover signaling procedure 2200 when a UE performs a handover and thenetwork decides not to change the allocated anchor. If UE1 changes itspoint of attachment and connects to PoA03, the initial attachmentsignaling may be received by PoA03, which may forward this signaling tothe SDN controller, as PoA03 does not have a mapping for that traffic.The SDN controller may look into the database for UE1 and find out thatit was already attached to the network, and obtain the information aboutcurrent anchors, allocated addresses and NAT state. Taking thisinformation into consideration, together with additional one, such as,but not limited to, network status, UE known mobility pattern, and thelike, the SDN controller may decide to select a different anchor for newUE2 sessions. The controller may first update the new best path forUE1′s traffic anchored at SW05(UE1<->PoA03<->SW04<->SW03<->SW02<->SW05<->R01 in this example) and maythen update involved network entities.

When UE1 starts a new IPv4 data flow, these packets may be received byPoA02, which may not have any matching rules, and therefore may forwardthe packets to the SDN controller. The SDN controller may compute theNAT required translation and set up the forwarding data plane in thenetwork using SW07 as the new selected break-out point(UE1<->PoA03<->SW04<->SW07<->R02, which happens to be symmetric just forthe sake of simplifying the example). Since the anchor point may havechanged, a new public IPv4 address (198.51.100.1) may be used for theUE1's data packets that are anchored at SW07. The controller mayconfigure the different involved network entities, including not onlythe data plane forwarding entries, but also the packet leveltransformations that may be performed at the anchoring point, which mayalso play the role of NAT device (SW07 in this example). The databasemay also be updated by the SDN controller. Only one IP data flow peractive anchor point may be considered, showing the NAT operations andthe flow path forwarding setup in the network. For each new started dataflow of the UE, analogous operations may take place, which may keep thetraffic anchored at SW07.

FIGS. 23A-23C show an example of IPv4 support for a new anchorallocation signaling procedure 2300 when the network decides to allocatea new anchor to a UE, even if it has not moved. UE1 is attached to PoA02and is currently using SW05 as its local break-out point. At a givenpoint of time, the SDN controller may decide to assign a differentanchoring entity for new IP traffic data flows of UE2 (for examplebecause of maintenance reasons). FIGS. 23A-23C shows that existingflows, anchored at SW05, may not be impacted, but that for new dataflows, when PoA02 forwards the first packet to the SDN controller (asthere is no matching rule), the SDN controller may select a new anchor(SW07 in this example), allocate a new public IPv4 address(198.51.100.1), and compute the forwarding path for traffic between theUE2 and the SW07 (which happens to be symmetric for the sake of thesimplicity of this example: UE1<->PoA02<->SW03<->SW04<->SW07<->R02), aswell as the per-packet transformations required by the NAT. From thispoint, new traffic sessions may use the new anchor, while old ones keepusing the previously selected one(s).

Although features and elements are described above in particularcombinations, one of ordinary skill in the art will appreciate that eachfeature or element may be used alone or in combination with any of theother features and elements. In addition, the embodiments describedherein may be implemented in a computer program, software, or firmwareincorporated in a computer-readable medium for execution by a computeror processor. Examples of computer-readable media include electronicsignals, (transmitted over wired or wireless connections), andcomputer-readable storage media. Examples of computer-readable storagemedia include, but are not limited to, a read only memory (ROM), arandom access memory (RAM), a register, a cache memory, a semiconductormemory device, a magnetic media, (e.g., an internal hard disc or aremovable disc), a magneto-optical media, and an optical media such as acompact disc (CD) or a digital versatile disc (DVD). A processor inassociation with software may be used to implement a radio frequencytransceiver for use in a WTRU, UE, terminal, base station, Node-B, eNB,HNB, HeNB, AP, RNC, wireless router or any host computer.

Furthermore, although specific signaling and examples have beendescribed above, it should be noted that alternative signaling may beutilized in the procedures described above, and any number of componentsmay be in communication with one another. For example, although specificswitches, UEs, SDN controllers, and PoAs are described in the examplesabove, any number or combination of the components may similarly beutilized in the procedures described above.

1. A method for use in a software defined network (SDN) controller of anetwork, comprising: receiving an initial attachment signaling from afirst point of attachment (PoA) node indicating that a wireless transmitreceive unit (WTRU) is attached to the network; determining if the WTRUis currently attached to the network by checking a database; selecting afirst anchor node to provide connectivity to the WTRU, wherein theselecting the first anchor node is based on at least one of thefollowing criteria: expected mobility patterns of the WTRU, knownmobility patterns of the WTRU, speed of the WTRU, status of the network,load of the network, or capabilities of the network; configuring aforwarding data plan plane to allow signaling to reach the first anchornode; and configuring the forwarding data plane between the first anchornode and the WTRU to allow data packets to be forwarded between the WTRUand the first anchor node.
 2. The method of claim 1 further comprising:updating the database with an identifier of the selected first anchornode.
 3. The method of claim 2 wherein the database is a home subscriberserver (HSS).
 4. The method of claim 1 wherein the first anchor node isa distributed gateway (D-GW).
 5. The method of claim 1, furthercomprising: selecting a second anchor node to provide connectivity tothe WTRU, wherein the selecting the second anchor node is based on atleast one of the following criteria: expected mobility patterns of theWTRU, known mobility patterns of the WTRU, speed of the WTRU, status ofthe network, load of the network, or capabilities of the network;configuring a forwarding data plan plane to allow signaling to reach thesecond anchor node; and configuring the forwarding plane between thesecond anchor node and the WTRU to allow data packets to be forwardedbetween the WTRU and the second anchor node.
 6. The method of claim 5,further comprising discontinuing the forwarding data plane between thefirst anchor node and the WTRU.
 7. The method of claim 1, furthercomprising receiving signaling from a second PoA node indicating thatthe WTRU is attached to the network.
 8. The method of claim 7, furthercomprising reconfiguring the forwarding data plane between the firstanchor node and the WTRU to allow data packets to be forwarded betweenthe WTRU and the first anchor node based upon a determination that thefirst anchor node is to continue providing connectivity to the WTRU. 9.The method of claim 7 wherein based on a condition that the first anchornode is to discontinue providing connectivity to the WTRU, the methodfurther comprising: selecting a second anchor node to provideconnectivity to the WTRU, wherein the selecting the second anchor nodeis based on at least one of the following criteria: expected mobilitypatterns of the WTRU, known mobility patterns of the WTRU, speed of theWTRU, status of the network, load of the network, or capabilities of thenetwork; configuring a forwarding data plane to allow signaling to reachthe second anchor node; and configuring the forwarding data planebetween the second anchor node and the WTRU to allow data packets to beforwarded between the WTRU and the second anchor node.
 10. The method ofclaim 1, further comprising computing a network address translation(NAT).
 11. A software defined network (SDN) controller, comprising: aprocessor and a transceiver configured to receive an initial attachmentsignal from a first point of attachment (PoA) node indicating that awireless transmit/receive unit (WTRU) is attached to the network; theprocessor and the transceiver configured to determine if the WTRU iscurrently attached to the network by checking a database; the processorand the transceiver configured to select a first anchor node to provideconnectivity to the WTRU, wherein the processor and the transceiver areconfigured to select the first anchor node based on at least one of thefollowing criteria: expected mobility patterns of the WTRU, knownmobility patterns of the WTRU, speed of the WTRU, status of the network,load of the network, or capabilities of the network; the processor andthe transceiver configured to determine a forwarding data plan plane toallow signaling to reach the first anchor node; and the processor andthe transceiver configured to determine the forwarding data plan planebetween the first anchor node and the WTRU to allow data packets to beforwarded between the WTRU and the first anchor node.
 12. The SDNcontroller of claim 11, wherein: the processor and the transceiver arefurther configured to select a second anchor node to provideconnectivity to the WTRU, wherein the processor and the transceiver areconfigured to select the second anchor node based on at least one of thefollowing criteria: expected mobility patterns of the WTRU, knownmobility patterns of the WTRU, speed of the WTRU, status of the network,load of the network, or capabilities of the network; the processor andthe transceiver are further configured to determine a forwarding dataplane to allow signaling to reach the second anchor node; and theprocessor and the transceiver are further configured to determine aforwarding data plane between the second anchor node and the WTRU toallow data packets to be forwarded between the WTRU and the secondanchor node.
 13. The SDN controller of claim 12, wherein: the processorand the transceiver are further configured to discontinue the forwardingdata plane between the first anchor node and the WTRU.
 14. The SDNcontroller of claim 11, wherein: the processor and the transceiver arefurther configured to receive a signal from a second PoA node indicatingthat the WTRU is attached to the network.
 15. The SDN controller ofclaim 14, wherein: the processor and the transceiver are furtherconfigured to redetermine the forwarding data plane between the firstanchor node and the WTRU to allow data packets to be forwarded betweenthe WTRU and the first anchor node based upon a determination that thefirst anchor node is to continue providing connectivity to the WTRU. 16.The SDN controller of claim 14, wherein based on a condition that thefirst anchor node is to discontinue providing connectivity to the WTRU:the processor and the transceiver are further configured to select asecond anchor node to provide connectivity to the WTRU, wherein theprocessor and the transceiver are configured to select the second anchornode based on at least one of the following criteria: expected mobilitypatterns of the WTRU, known mobility patterns of the WTRU, speed of theWTRU, status of the network, load of the network, or capabilities of thenetwork; the processor and the transceiver are further configured todetermine a forwarding data plane to allow signaling to reach the secondanchor node; and the processor and the transceiver are furtherconfigured to determine a forwarding data plane between the secondanchor node and the WTRU to allow data packets to be forwarded betweenthe WTRU and the second anchor node.
 17. The SDN controller of claim 11,wherein: the processor and the transceiver are further configured tocompute a network address translation (NAT).